1. Field of Invention
The present invention relates generally to the field of computer information archiving and backup recovery. More specifically, the present invention is related to the control of a filesystem recovery process by a database management system. The method of this invention has particular application in restoring a filesystem and files to any point in time in the event of a filesystem crash.
2. Discussion of Prior Art
Data archiving and restoration have always been important to critical computer applications and data. The prior art in this area describes many different approaches to improving speed, reliability, efficiency, and storage requirements of archival solutions. Independently, database management systems (DBMS) have undergone their own development. Aside from the various models such as relational, hierarchical and object-oriented, database management systems have evolved to manage visual, binary and even distributed data. The application of DBMS principles to filesystem archival and recovery, however, has not been adequately addressed as indicated in the following discussion of related prior art.
The patent to Elliott et al. (4,945,474) provides for a database transaction logging method which allows operational recovery after an I/O error. The disclosed restoration is limited to a database rather than restoring the underlying filesystem.
The patent to Combs et al. (5,577,220) describes a mechanism for taking a snapshot of a CPU state and restoring to that state if needed. The system described can only be restored to the snapshotted state rather than any previous state.
The patent to Hanes (5,754,848) provides for a disaster recovery system which first restores a traditional filesystem (i.e 8.3 filenames) which has libraries to allow subsequent recovery using long filenames. The described method relates to translating between filenaming conventions rather than maintaining a recoverable history of filesystem operations.
The patent to Masada (5,754,782) provides for a document backup and restoration system in a GroupWare environment. However, no discussion of combining both a database restoration and a filesystem recovery is provided.
The patent to Whiting et al. (5,778,395) provides for a space reducing data archiving system which stores only file changes after an initial filesystem snapshot is stored, but fails to discuss synchronizing a particular version with an accompanying database state.
The patent to Luick (5,793,944) describes a hardware method of data storing and restoring upon the occurrence of a variety of errors and is limited to teaching a method of capturing various hardware states rather than capturing filesystem directory structure states.
The patent to Bailey et al. (5,794,252) provides for a database transaction logging system to assist with database duplication. The logging system discussed, however, fails to consider the maintenance of filesystem directory transactions.
The patent to Morris (5,813,017) provides for a distributed data backup system which reduces transmission bandwidth and storage requirements by archiving files as delta (i.e changed) files across a network. However, no teaching is provided which synchronizes a retrieved delta version with a desired database restoration state.
The IBM Technical Disclosure Bulletin entitled xe2x80x9cTable Relocation Alternative For Restorexe2x80x9d describes an interactive method of restoring backed-up data to a filesystem having a different structure than that of the filesystem from which it was originally archived; although, no provision for restoring the filesystem is discussed.
The IBM Technical Disclosure Bulletin entitled xe2x80x9cMethod to Ensure the Integrity of File Operations in a Database Transactionxe2x80x9d teaches a COMMIT and ROLLBACK algorithm to ensure database transactions do not leave a filesystem in an inconsistent state. However, relating the consistent database to a previous directory structure is not taught.
The IBM Technical Disclosure Bulletin entitled xe2x80x9cChanged Data Only Backup and Recoveryxe2x80x9d details a multi-version backup system which archives only changes to files which have previously been archived but fails to discuss how to restore files to an underlying filesystem directory structure which might also have changed.
Whatever the precise merits, features and advantages of the above cited references, none of them achieve or fulfill, individually or in combination, the purposes of the present invention. They fail to provide for a database managed table which logs filesystem directory operations and without such a log, the prior art fails to teach a method of restoring a filesystem directory structure to a previous known state. Furthermore, without a point-in-time directory recovery method, the above mentioned prior art fails to provide for a method of synchronizing a database restore to a filesystem directory structure restore and file restore.
A database management system (DBMS) is used to maintain a record of a filesystem""s directory structure (registry database). The creation, removal or update of a directory results in a record, pertaining to that event, being stored into a database table of similar events. In addition, files are also linked to a DBMS (user database) and archived according to its management rules (i.e. DBMS references and/or controls the linked files). In the event of a filesystem crash, the DBMSs are used to restore the filesystem through the use of the directory structure database table which allows reconstruction of the filesystem to any previous filesystem state. Furthermore, files can then be recovered to match that state and thereby reconcile external files linked to a database to any previous state.
While described as two separate databases, implementing the registry database and the user database as a single database is also considered within the scope of the present invention. The registry database and the user database are logical entities and mapping them to the same physical database is functionally equivalent to mapping them to two different physical databases. One difference worth mentioning, however, is that the registry database is created by the system and is not normally visible to users, while the user database is created by the user. Throughout this specification, DBMS is used when generally referring to these databases regardless of their actual physical mapping.